Ah, just after (of course!) submitting the PR, I realized two things:

1. The new index_sizes(s::Size, inds...) will error if s contains fewer elements than inds. Is that a problem? The fix should be trivial.
2. code_warntype(DevNull, StaticArrays.index_sizes, Tuple{Vararg{Any}}) is able to trigger the error so would make a good test. Update incoming...

Coverage decreased (-0.01%) to 69.605% when pulling 81c0a22 on martinholters:mh/index_sizes into 8d3ec32 on JuliaArrays:master.

Coverage increased (+0.03%) to 69.652% when pulling bfe0273 on martinholters:mh/index_sizes into 8d3ec32 on JuliaArrays:master.

Fixed the the case for s containing fewer elements than inds (in case that matters).

Coverage increased (+0.1%) to 69.714% when pulling 09a86d0 on martinholters:mh/index_sizes into 8d3ec32 on JuliaArrays:master.

Thanks for working on this!

I'm on vacation for another week, so I can't have an in depth look at the moment. I can say I'm very happy this is being looked at.

I assume someone has (or will) check the generated code? Other than that, I think I'm ok with this PR.

I don't think I'm sufficiently familiar with this package to check the generated code. I've done some very basic benchmarking of indexing:

sm = @SMatrix [1 2 3; 4 5 6]
sv = @SVector [1, 2]
@benchmark $sm[$sv, 1]
@benchmark $sm[1, $sv]
@benchmark $sm[:, $sv]
@benchmark $sm[$sv, :]
@benchmark $sm[1, :]
@benchmark $sm[1, 1]
@benchmark $sm[:, 1]
@benchmark $sm[:, :]

They are all within measurement between master and this PR. I've also checked @code_warntype sm[:, 1] as one example and it is identical between master and this PR. But these probably aren't the critical cases?

Thanks for tackling this one. It's very pleasing that your new implementation avoids any mention of Val :-)

Regarding your struct Foo problem, the way I've been dealing with this is as follows:

@testset "blah" begin

# ... lots of other tests ...

# Now the test which needs a custom type
@eval struct Foo
    i::Int
end

# Some test using Foo
@test Foo(1).i == 1

end

Of course the type Foo is still defined globally within the current module, but at least the code for it is next to the test which needs it.

I don't think it would be worth the effort, so: no. If anyone disagrees, I'd be happy to add it, but not in the next couple of days.

Sure no problems. I had a quick look but it seems to be obscure behavior which would be better as a compiler test.